Postscript®-based publishing workflows known in the art use job ticketing embedded in Postscript® (PS) files to control output devices. The embedded job ticketing may, e.g., take the form of setpagedevice (SPD) commands that are read by an interpreter and used to execute page programming or finishing programming, whether at the document, section or page exception level. As Postscript®-based publishing workflows are moved to Portable Document Format (PDF)-based workflows, this embedded programming functionality is being left behind without any clear replacement. Separate job ticketing for PDF workflows may not allow all the possible command combinations that can be achieved by writing the commands into the Page Description Language (PDL) file. Furthermore, the PDF job ticket, which is external to the PDF file proper, may lose its association with the PDF file as the file winds its way through the end-to-end workflow. The above-mentioned PostScript® and PDF file formats are described in more detail in PostScript® Language Reference, Third Edition, and PDF Reference, fifth edition, Adobe® Portable Document Format, Version 1.6, both by Adobe Systems Incorporated.
The loss of programming functionality is particularly noticeable with mainframe computers. Mainframes can output PS files with embedded programming for user-specified parameters such as, e.g., mapping to different media, chapter starts, page offset, finishing options, stapling groups (variable group sizes), etc. Since migrating to PDF would result in a net loss of functionality, mainframe systems continue to generate Postscript® output when submitting documents for printing. By generating Postscript® files, SPD commands can remain within the PDL file as described above and are supported by a wide range of Digital Frontends (DFEs). One current solution is the above-mentioned separate job ticketing to provide a separate file (Job Ticket), describing how the job is to be processed. However, one disadvantage of such an approach is that the Job Ticket assumes the PS file has been created. Yet in many cases it would be desirable to be able to start printing the PS file before it has been completely generated. In these cases, PS file creation, RIPping and printing all happen concurrently. The separate job ticketing imposes a needless constraint that can cause difficulties when printing very long print runs. Additionally, more detailed specifications can be provided if the Job Ticket information is written out directly with the PS file. The UI used to create the Job Ticket separately would be overly cumbersome to a user if it provided all of the available features and/or options that are possible by using predefined content rules. This would lead to an unnecessary source for errors. It would be less cumbersome and less error prone if the parameters could be concurrently embedded in the print job by the system creating the print job when the system is aware of the user context/contents of the print job. This is a particularly noticeable problem for mainframe printers having large print jobs. Large print jobs may comprise hundreds or thousands of print pages such as, e.g., in universities where a professor may put together courses including material selected from numerous sources, requiring different colors, separators, etc.
However, there is a need for a method that enables migrating embedded job ticketing workflows, e.g., SPD-based Postscript® workflows, to PDF workflows without losing job programming features or capabilities. It would be particularly advantageous for the migration method to have minimal impact on current systems currently utilizing SPD-based Postscript® workflows.